Summary

This PR:

• Improves Language Limitation by limiting user's ability to create, edit and publish content in a given language to a list of translations set by that Limitation.
• e6e5aa0 implements PermissionResolver::lookupLimitations which provides more standardized and API-oriented way to fetch information about existing Limitations for the given object in the context of the given policy (by @mikadamczyk).

Squashed into one PR due to time constraints.

Implementation details

Many Limitations throw exception when dealing with unknown objects or targets, which makes it impossible to set some specific mixes of Limitations on a given policy. This had hit us in the past and now makes current changes impossible to implement.

To solve this issue we're introducing two new interfaces:

• \eZ\Publish\SPI\Limitation\Target which is a marker for a new Target object which is designed in a new way and provides more information about an intent of a canUser check.
• \eZ\Publish\SPI\Limitation\TargetAwareType for LimitationType (service which implements Limitation evaluation logic) which does not throw exception when dealing with an unknown object. Such LimitationType should at the end return ACCESS_ABSTAIN. TargetAwareType LimitationType expects $targets to be an array of instances of Target, however if different object is passed, it won't throw exception (behaves as described).

We've created the first class which objects follows the described behavior:

• \eZ\Publish\SPI\Limitation\Target\Version

and a builder for DX and readability

• \eZ\Publish\SPI\Limitation\Target\Builder\VersionBuilder
  which provides behavioral, intent-driven API.

Consider the following updateContent use case:

        $this->repository->getPermissionResolver()->canUser(
            'content',
            'edit',
            $content,
            [
                (new Target\Builder\VersionBuilder())
                    ->updateFieldsTo(
                        $contentUpdateStruct->initialLanguageCode,
                        $contentUpdateStruct->fields
                    )
                    ->build(),
            ]
        )

it checks if a user is able to edit the Content if new Version would contain new initial language and given fields (actually used only to extract language codes of modified translation).

Limitation\Target\Version is passed as one of the targets to the following ContentService methods:

• createContentDraft // from existing Version
• updateContent
• publishVersion // not needed

We could try handling ContentUpdateStruct, but this Target is also designed to provide Limitation lookup for which creating artificial update struct is an overkill.

To provide BC for existing Limitations other than Language and avoid known issues when mixing Limitations for a single policy, the logic of PermissionResolver::canUser is changed as follows:

• for LimitationTypes not implementing Limitation\TargetAwareType only targets which are not instances of Limitation\Target are passed (array is filtered prior passing). If an array is empty, null is returned as some Limitations rely on that.
• for Target-aware Limitation types (implementing Limitation\TargetAwareType) only targets which are instances of Limitation\Target are passed.

TODO:

• Cover COTF requirements mix (Translation, Content type, Parent Location) with integration tests.
• Implement Languages diff to determine if publishing should be allowed.
• Fix new code according to Coding Standards ($ composer fix-cs).
• Ask for Code Review.